在前幾篇，我們已經有了「 房門與門鎖 」的表單驗證，也做好「 屋況驗收 」。但如果門鎖只是裝飾，任何人都能翻窗進來，那這棟房子還是非常危險。
這時候，就需要 Firebase Rules，它就像「 守衛 」一樣，確保只有擁有正確身份的人，才能存取正確的資料。

Firebase Rules

Firebase Rules 是針對 Firestore 與 Storage 的存取控制規則。
它不像後端 API 可以用程式碼撰寫邏輯，而是用一種類似 DSL 的語法，直接設定「誰能做什麼」。

舉例來說：

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /tasks/{taskId} {
      // 只有登入者本人才能讀寫自己 task
      allow read, write: if request.auth != null && request.auth.uid == resource.data.userId;
    }
  }
}

為什麼需要 Firebase Rules？ 和後端 API 驗證有什麼不同？

即使前端有驗證，使用者依然能繞過 UI，直接透過 API 或 SDK 存取資料。
因此必須要有 Rules 在 資料存取層 做最後一道防線。

• 後端 API 驗證：在程式碼層面處理，可以撰寫複雜邏輯。
• Firebase Rules：貼近資料層，效能高、不需額外伺服器，適合存取控制。

如果 Rules 寫錯會怎樣？

• 過度開放：allow read, write: if true → 任何人都能看到或修改資料，造成外洩。
• 過度嚴格：全部 deny → 連自己都無法存取，系統直接卡死。

所以 Rules 一定要搭配 Firebase Emulator + 測試 一起驗證。

常見的應用場景

1. 限制未登入使用者 — 確保必須登入才可操作。

allow read, write: if request.auth != null;

2. 只能修改自己的資料 — 避免使用者修改別人的 task。

allow update, delete: if request.auth.uid == resource.data.userId;

3. 限制欄位內容 — 避免有人亂改系統欄位 ( 例如 createdAt )

allow create: if request.resource.data.keys().hasOnly(['title', 'createdAt'])
              && request.resource.data.createdAt == request.time;